Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

@googlebot I signed it!

My question is - what should be done when there are lots of combinations of W and L parameters? Should I introduce some steps for those values, or limits? We could possibly make some custom legend so it would fit into the plot, but still the plot lines would overlap heavily in some places.

My question is - what should be done when there are lots of combinations of W and L parameters? Should I introduce some steps for those values, or limits? We could possibly make some custom legend so it would fit into the plot, but still the plot lines would overlap heavily in some places.

It seems like grouping the plots for different W values (1.0, 3.0, 5.0, 7.0) might work?

You should ask on the #analog-design channel on slack about what people would find most useful

According to the gm/Id theory you only need to do the plot for one width because you're looking for the current density, drain current/width. So you would sweep the current density for each length to get the plots.

That's the theory anyway, it falls over at the extremes but for the central regions of Id/W it should hold true.

I added grouping plots for the different W values. There is also a possibility to explicitly tell what W values should be considered for plots (in --only-w parameter in https://github.com/antmicro/skywater-pdk/blob/200-generate-bin-plots/scripts/python-skywater-pdk/skywater_pdk/fet_simulator/fet_simulator.py or in https://github.com/antmicro/skywater-pdk/blob/200-generate-bin-plots/scripts/python-skywater-pdk/skywater_pdk/fet_simulator/generate-docs-plots.py, where None values should be replaced by a list of desired W values).

I also moved legend outside the plot so it does not cover title or plots:

During generation of FET plots it turned out that for some bins.csv files the content is invalid, e.g. for https://foss-eda-tools.googlesource.com/skywater-pdk/libs/sky130_fd_pr/+/refs/heads/master/cells/nfet_20v0_nvt_iso/sky130_fd_pr__nfet_20v0_nvt_iso.bins.csv we have:

device,bin,W,L
model corner
,0,30.0,1.0

instead of

device,bin,W,L
sky130_fd_pr__nfet_20v0_nvt_iso,0,30.0,1.0

This occurs for:
https://foss-eda-tools.googlesource.com/skywater-pdk/libs/sky130_fd_pr/+/refs/heads/master/cells/nfet_20v0_nvt_iso/sky130_fd_pr__nfet_20v0_nvt_iso.bins.csv
https://foss-eda-tools.googlesource.com/skywater-pdk/libs/sky130_fd_pr/+/refs/heads/master/cells/nfet_20v0_nvt/sky130_fd_pr__nfet_20v0_nvt.bins.csv
https://foss-eda-tools.googlesource.com/skywater-pdk/libs/sky130_fd_pr/+/refs/heads/master/cells/nfet_20v0_nvt_iso/sky130_fd_pr__nfet_20v0_nvt_iso.bins.csv
https://foss-eda-tools.googlesource.com/skywater-pdk/libs/sky130_fd_pr/+/refs/heads/master/cells/nfet_20v0_zvt/sky130_fd_pr__nfet_20v0_zvt.bins.csv

Later, the bins.csv files are missing for nfet_20v0 and nfet_g11v0d16v0 cells - should I use some default values of bin, W and L in such scenarios?

In the end, the PySpice ends successfully but does not provide values for gm_id, id_W, ft and gm_gds for the simulation of pfet_20v0 and pfet_g5v0d16v0 cells.

@glatosinski - Please log bugs for those other issues.

The plots don't seem to be included in the documentation anywhere?

I am not sure what is the final destination for those generated files - should they end up in corresponding FET directories in docs/rules/device-details, or in some separate repository for intermediate results?

Is this working with the rf_* fet models? When I wrote the original, it did not because these models are actually subcircuits with multiple FETs so you can't get a gm from an internal parameter and likely will have to calculate from the Vgg and Iout. Are gm values composable? (can we combine the individual gm values in the constituent fets?)